Avoid blocking filesystem checks in the recent documents menu - #733

When the recent-document list contains files on an unavailable network automount, opening an unrelated document can freeze Xreader. Closing the window also stops responding because ev_window_setup_recent() calls gtk_recent_info_exists() on the UI thread. A file:// URI can point to an automounted network share, so gtk_recent_info_is_local() does not make this check safe.

Remove the existence check when building the File menu's recent-document list. Keep filtering by application, sorting and limiting the entries as before. File access and errors are handled by the existing document-loading path when the user selects an entry.

This means missing or temporarily unavailable documents remain listed. That is consistent with the existing toolbar recent chooser, whose GTK show-not-found default is true, and avoids filesystem I/O just to populate the menu.

Related: #32. Reproduced with Xreader 4.6.5; the same check is present on current master (4.6.9).

Validation:

• Reproduced the original freeze with three recent PDFs on an unreachable CIFS automount. strace showed repeated newfstatat() calls on the UI thread, each taking approximately 6.2 seconds before returning ENODEV.
• Built the patched current-master viewer and PDF backend with Meson/Ninja (PDF enabled; optional PS, TIFF, XPS, keyring, thumbnailer and previewer disabled).
• Ran the newly built viewer without the local workaround, using an existing sample PDF while retaining the unavailable-share entries in recent history. The PDF opened, the trace contained zero accesses to that share, and the window closed normally in 0.043 seconds.
• git diff --check passes.